1. Field of the Invention
The present invention relates to a database-rearranging program, a database-rearranging method, and a database-rearranging apparatus, and more particularly to a database-rearranging program, a database-rearranging method, and a database-rearranging apparatus, which perform rearrangement of a database while continuing transactions on the database.
2. Description of the Related Art
In lots of database systems, it is necessary to rearrange a database so as to maintain an efficient data input and output environment. For example, the rearrangement is carried out for the following purposes:                Integration of free areas existing between records in pages (resolving fragmentation)        Enhancement of access performance, by moving records in overflow pages into prime pages        Expansion of the data storage area of the database before it is filled with records        
In a conventional general rearranging process, first, all the records in the database are saved in an intermediate file. Then, after executing the expansion of the capacity of the database or like processing, the saved data is restored in the database.
FIG. 10 is a diagram illustrating a conventional general database-rearranging method. In FIG. 10, there is shown an example of the case where the data of a database 911 are rearranged and stored in a database 921.
The database 911 has a prime pages storage area 911a for storing a plurality of prime pages, and an overflow pages storage area 911b for storing a plurality of overflow pages. The prime pages are basic storage areas for storing records. Prime pages where records should be stored are defined in advance by an index 912.
The overflow pages are storage areas for storing records which cannot be stored in prime pages associated therewith due to shortage of available space of the prime pages. When records are stored in an overflow page, a pointer is set in a prime page where the records should have been stored, which points to the overflow page where the records are actually stored.
When rearranging the database 911, first, the records in the database 911 are saved in a storage medium 930, such as a magnetic tape (step S101). The saving of data is carried out in the increasing order of page numbers, starting with the first page of the prime pages, according to the index information. When there are overflow pages which are pointed to by respective pointers in the associated prime pages, after records in one prime page are saved, records in the associated overflow page are saved, sequentially. This saving process is repeatedly carried out to the last page.
Next, an index 922 is prepared again, and the database 921 expanded in capacity is constructed (step S102). In the prepared index 922, pages for storing records are defined such that all the records are stored in the prime pages storage area 921a. The database 911 in the storage device is once erased, and subsequently, the database 921 expanded in capacity is reconstructed. Then, the records saved in the recording medium 930 are restored in the database 921 (step S103).
Thus, the database can be rearranged. By executing storage of records into the database 921 according to the designation of the index 922 newly prepared, more prime pages, for example, become available, which enhances the access performance of the database 921. Further, when records are stored thereafter, overflow pages are not formed additionally, since certain amounts of space have been produced in the prime pages, which makes it possible to prevent degradation of the access performance.
However, this database-rearranging method necessitates stoppage of processing, such as updating of the database 911, during a time period between saving of the records and restoration of the same. This is because the data cannot be guaranteed if records are stored during rearrangement of the database. This makes it impossible to apply this method to systems which are required to operate on a 24-hour basis. Therefore, a method is necessitated which enables execution of the database rearrangement during operation of processing functions involving access to the database.
FIG. 11 is a diagram illustrating a method for executing the database rearrangement without stopping access to the database. In this method, separately from a database 941 (copy source) which is accessed by a processing function using the database, a database 951 (copy destination) for execution of the rearrangement is newly provided in advance. The databases 941 and 951 are provided with respective associated indexes 942 and 952. Further, the database 941 has a prime pages storage area 941a for storing a plurality of prime pages, and an overflow pages storage area 941b for storing a plurality of overflow pages. Similarly, the database 951 has a prime pages storage area 951a for storing a plurality of prime pages, and an overflow pages storage area 951b for storing a plurality of overflow pages. In the illustrated example, it is assumed that the database 951 has a larger storage capacity than the database 941.
The records stored in the pages of the database 941 as the copy source are sequentially copied to the database 951 as the copy destination, starting with the first page thereof, thereby executing the rearrangement of the database (step S111).
At this time, a transaction 961 can be received which intends to update records stored in the database 941 as the copy source. For example, a record (record number “R1”) in a prime page is altered by the transaction 961, and a record (record number “R33”) is added to an overflow page (step S112). When the processing for updating the records is executed during the rearrangement, the contents of the updating processing are recorded in an after-update log 943 (step S113).
Here, assuming that an application program updates records thus copied, the after-update log 943 concerning the copied records is added in to the records in the database 951 as the copy destination (step S114). The term “add in” is intended to mean processing in which the contents of the updated records are reflected in the database 951. By executing the add-in processing, the old records are overwritten by the updated records whereby the matching between the data in the copy source and the data in the copy destination is guaranteed. This type of method of updating the database is called “DB snapper” (see e.g. Japanese Unexamined Patent Publication (Kokai) No. 2000-339210).
In the method shown in FIG. 11, until the after-update log 943 is added in, the latest property of the data cannot be guaranteed. Therefore, the transaction 962 involving the access to the rearranged database 951 is rejected even if it is for referring to the database 951 (step S115). In the example shown in FIG. 11, during the add-in processing, a transaction 962 is carried out which involves referring to a record having a record number “R11”. At this time, the copying of the record to the database 951 as the copy destination is not completed yet, the instant reference cannot be carried out (due to time lag). When the add-in processing of the after-update log 943 to the database 951 as the copy destination is completed, the reference to the record is permitted thereafter.
It is also possible to duplicate data in units of blocks, and perform management by checking whether or not the rearrangement is completed on a block-by-block basis, and in this case, an access to a block of which the rearrangement is completed is performed on the database as the copy destination. On the other hand, an access to a block of which the rearrangement is not completed is performed on the database as the copy source. Further, an access to a block being copied is performed on the database as the copy destination after completion of copying (see e.g. Japanese Unexamined Paten Publication (Kokai) No. H05-151037).
However, in the method shown in FIG. 10, during the execution of add-in of the log, the access to the database is inhibited. More specifically, after a record is updated and until the log of the update is reflected, the latest property of the copied record cannot be guaranteed. Therefore, an application program cannot instantly use the record.
According to the method described in Japanese Unexamined Patent Publication (Kokai) No. H05-151037, the rearrangement of the database can be carried out without stopping the access to records. However, when a malfunction or the like occurs in the system, destroying contents of the database, it is difficult for this method to correctly restore the database. That is, according to this method, when contents of a copied block are updated, the records of the block are written into the database as the copy destination alone. Therefore, the updating process of only the destination database is recorded in the after-update log.
At this time, if a malfunction occurs in the database as the copy source during the processing of the rearrangement, the contents of the database as the copy source are restored to the state backed up in the past. Even if the contents of the after-update log storing contents of update made on the database as the copy source are reflected in the database in this state, the contents of the updating processing carried out on the destination database are not reflected. This makes it difficult to guarantee the records written in the destination database. Therefore, this method cannot be applied to systems of which high reliability is demanded, such as a system for managing bank accounts.